Extending a dhcp relay to backup a dhcp server

ABSTRACT

Techniques are described for providing a backup DHCP server using a DHCP relay agent. Embodiments retrieve DHCP server configuration information specifying a configuration of one or more DHCP servers. Additionally, embodiments monitor, at a DHCP relay agent, DHCP lease traffic between the one or more DHCP servers and one or more DHCP clients passing through the DHCP relay agent. Upon determining that the one or more DHCP servers have failed, DHCP server services are provided at the DHCP relay agent, based on the received DHCP server configuration information and the monitored DHCP lease traffic.

BACKGROUND

Embodiments presented in this disclosure generally relate to computernetworking and, more particularly, to techniques for providing a backupDynamic Host Configuration Protocol (DHCP) server at a DHCP relay agent.

Internet Protocol (IP) addresses are used to designate the destinationof IP communications. An IP address serves a purpose for networkcommunications similar to a street address for postal mail. In order fora device (or node) connected to an IP network to communicate over thenetwork with another node through an Internet Protocol, each node musthave an IP address and each node must reference the IP address of theother node. Further, each node must be configured such that it iscapable of determining a route to each other node with which it wishesto communicate. The IP address configuration information can be used todetermine routes to other nodes for the purposes of communication forman IP Configuration for a node.

There are several methods to provide a node on a network with an IPConfiguration. A node new to the network or which has been set to afactory default state may have a well known default IP configuration.For example, such a node could come preconfigured to use an address on anon-routable network. Alternatively, the IP network may utilize a DHCPserver. The DHCP server may have available a pool of IP addresses andmay assign an address from the pool to the node for a session on the IPnetwork. In this case, a DHCP Client on the node must be configured toaccept an IP address from a DHCP server. As another alternative, somecombination of DHCP and default configuration may be used to assign anode an IP Configuration.

Generally, DHCP gives network administrators a method to facilitateautomatic distribution of addresses and to maintain the networkconfiguration in a central location. More specifically, DHCP is anapplication-layer protocol that allows a client machine on a network toexchange packets between a software daemon on the client (i.e., a DHCPclient) with another on a DHCP server (i.e., a DHCP server application)to get an IP address. The DHCP server may lease the IP address toclients for some period of time, after which the lease of the IP addresswill expire. In such a scenario, the DHCP clients may have the option ofrenewing the lease of the IP address for an additional period of time.Additionally, such a period of time may be an infinite timeframe, suchthat the assigned IP address for the client remains the same withoutrequiring renewal.

SUMMARY

Embodiments provide a method, system and computer program product forproviding a backup DHCP server. The method, system and computer programproduct include retrieving DHCP server configuration informationspecifying a configuration of one or more DHCP servers. Additionally,the method, system and computer program product include monitoring, at aDHCP relay agent, DHCP lease traffic between the one or more DHCPservers and one or more DHCP clients passing through the DHCP relayagent. The method, system and computer program product also include,upon determining that the one or more DHCP servers have failed,providing DHCP server services at the DHCP relay agent, based on thereceived DHCP server configuration information and the monitored DHCPlease traffic.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the manner in which the above recited aspects are attained andcan be understood in detail, a more particular description ofembodiments of the invention, briefly summarized above, may be had byreference to the appended drawings.

It is to be noted, however, that the appended drawings illustrate onlytypical embodiments of this invention and are therefore not to beconsidered limiting of its scope, for the invention may admit to otherequally effective embodiments.

FIG. 1 is a diagram illustrating a system configured with a DHCP serverfailover component, according to one embodiment described herein.

FIG. 2 is a diagram illustrating a system configured with a DHCP serverfailover component, according to one embodiment described herein.

FIG. 3 is a flow diagram illustrating a method for providing a backupDHCP server, according to one embodiment described herein.

FIGS. 4A-B are flow diagrams illustrating methods for monitoring DHCPlease traffic, according to embodiments described herein.

FIG. 5 is a block diagram illustrating a system configured with a DHCPserver failover component, according to one embodiment described herein.

DETAILED DESCRIPTION

Embodiments presented herein generally relate to techniques forconfiguring a DHCP relay agent to act as a backup DHCP server. FIG. 1 isa diagram illustrating a system configured with a DHCP server failovercomponent, according to one embodiment described herein. As shown, thesystem 100 includes a plurality of DHCP clients 135 ₁₋₄ located acrosstwo subnets 140 _(1,3). Thus, in the depicted example, the DHCP clients135 ₁₋₂ are located on the subnet 140 ₁ of 10.0.1.0/24 and the DHCPclients 135 ₃₋₄ are located on the subnet 140 ₃ of 10.0.2.0/24. The DHCPclients 135 ₁₋₄ on the subnets 140 _(1,3) are connected to aintranetwork 120 via DHCP relay agents 125 ₁₋₂. Additionally, aplurality of DHCP servers 110 ₁₋₂ are shown as located on a third subnet140 ₂ of 10.0.0.0/24. The DHCP servers 110 ₁₋₂ are connected to theintranet 120 via a router 115.

Of note, in the depicted embodiment, the DHCP clients 135 ₁₋₄ arelocated on different subnets from the DHCP servers 110 ₁₋₂. As such, theDHCP clients 135 ₁₋₄ may be unable to communicate directly with the DHCPservers 110 ₁₋₂ in order to obtain leases on IP addresses. Toaccommodate for this, the DHCP relay agents 125 ₁₋₂ are configured torelay DHCP-related traffic from devices on a first subnet to devices ona second, different subnet. For instance, the DHCP relay agents 125 ₁₋₂could be software that executes on a network device such as a routerconnected to both subnets. In the depicted embodiment, the DHCP relayagents 125 ₁₋₂ are configured with a DHCP server failover component 130₁₋₂.

The DHCP server failover components 130 ₁₋₂ are configured to monitorDHCP-related traffic flowing through the DHCP relay agents 125 ₁₋₂ andto collect lease data. Such lease data may indicate, for example, whichIP addresses the DHCP servers 110 ₁₋₂ have leased out and which of theDHCP clients 125 ₁₋₄ these IP addresses are leased to. The DHCP serverfailover components 130 ₁₋₂ may also retrieve DHCP server configurationinformation from the DHCP servers 110 ₁₋₂. Such configurationinformation may specify, for instance, a range of IP addresses that eachof the DHCP servers 110 ₁₋₂ is configured to lease to clients.Additionally, each DHCP server failover component 130 is generallyconfigured to monitor the DHCP servers 110 ₁₋₂ and to determine when theDHCP servers 110 ₁₋₂ have failed or otherwise become unavailable. Forinstance, such unavailability could be caused by a network problem inthe company intranet 120 or in the router 115. As another example, theDHCP servers 110 ₁₋₂ could be unavailable due to a hardware or softwaremalfunction on the servers running the DHCP server applications. Moregenerally, however, the DHCP server failover component 130 is configuredto determine when the DHCP servers 110 ₁₋₂ are unavailable for anyreason.

Upon determining that the DHCP servers 110 ₁₋₂ are unavailable, the DHCPserver failover components 130 ₁₋₂ may assume the role of a backup DHCPserver, using the monitored lease data and the retrieved DHCP serverconfiguration information. That is, each of the DHCP server failovercomponents 130 ₁₋₂ may begin servicing DHCP lease requests for clients135 ₁₋₄ on the respective subnet 140 _(1,3). For example, upon detectingthat both DHCP servers 110 ₁₋₂ are unavailable, the DHCP server failovercomponent 130 ₁ could begin servicing DHCP requests for clients 135_(1,2) on the subnet 140 ₁. Continuing the example, if the client 135 ₁then requests an IP address, the DHCP server failover component 130 ₁could service this request and assign an available IP address to theclient 135 ₁. Furthermore, the DHCP server failover component 130 ₁could use the retrieved DHCP server configuration information todetermine the range of IP addresses that can be assigned to clients, andcould further use the monitored lease data to determine which IPaddresses are currently leased to clients. Based on this, the DHCPserver failover component 130 ₁ could select an available IP address andassign it to the client 135 ₁.

At some point in time, the DHCP server failover component 130 coulddetermine that the DHCP server 110 ₁ has once again become available(e.g., once the problem in the company intranet 120 is resolved). Upondetermining the DHCP server 110 ₁ is available, the DHCP server failovercomponent 130 ₁ could transmit updated lease information to the DHCPserver 110 ₁. Such updated lease information could specify, forinstance, which IP addresses the DHCP server failover component 130 ₁issued leases for and which clients these IP addresses were issued to.The DHCP server failover component 130 could resume relayingDHCP-related messages between the clients 135 _(1,2) and the DHCP server110 ₁. Advantageously, doing so allows the DHCP relay agents 125 ₁₋₂,each configured with a respective DHCP server failover component 130₁₋₂, to assume the role of a backup DHCP and to service DHCP-relatedrequests for the respective subnet 140 _(1,3) in the event the DHCPservers 110 ₁₋₂ become unavailable.

FIG. 2 is a diagram illustrating a system configured with a DHCP serverfailover component, according to one embodiment described herein. Asshown, the system 200 includes a plurality of DHCP servers 110 ₁₋₂. EachDHCP server 110 ₁₋₂ contains DHCP server configuration information 220₁₋₂. Generally, the configuration information 220 ₁₋₂ represents anydata related to the configuration of the respective DHCP server 110 ₁₋₂.For instance, such data could include a range of IP addresses to bedynamically assigned, a set of IP addresses that clients are currentlyleasing, which clients are currently leasing which IP address, thedefault duration of a new lease, the maximum lease duration, any staticIP address configurations and so on. These examples are provided forillustrative purposes only and without limitation, and it is broadlycontemplated that the configuration information 220 ₁₋₂ represents anydata associated with the configuration and/or status of the respectiveDHCP server 110 ₁₋₂.

In the depicted system 200, the DHCP servers 110 ₁₋₂ are connected tothe network 210. Generally, the network 210 represents any form ofcomputer network. Additionally, a DHCP relay agent 120 configured with aDHCP server failover component 130 is connected to the network 210. TheDHCP relay agent is further connected to a plurality of clients 135 ₁₋₃.For purposes of this example, assume that the DHCP servers 110 ₁₋₂ areconnected to a first subnet and the clients 135 ₁₋₃ are connected to asecond, different subnet. As discussed above, the DHCP relay agent 120is generally configured to relay DHCP-related messages between theservers 110 ₁₋₂ on the first subnet and the clients 135 ₁₋₃ on thesecond subnet. Doing so allows clients on one or more subnets to accessa DHCP server residing in a different subnet.

In the depicted embodiment, there is a network disconnect 230 betweenthe DHCP relay agent 120 and the network 210. As a result, the DHCPrelay agent 120 in the present example is unable to communicate with theDHCP servers 110 ₁₋₂ over the network 210. In such a scenario, the DHCPserver failover component 130 could detect that the DHCP servers 110 ₁₋₂are unavailable to service DHCP requests. For instance, the DHCP serverfailover component 130 could be configured to periodically attempt tocommunicate with the DHCP servers 110 ₁₋₂ in a way that elicits aresponse from the servers 110 ₁₋₂. In such a scenario, if the DHCPserver failover component 130 does not receive the response from theDHCP servers 110 ₁₋₂ within a predetermined period of time, the DHCPserver failover component 130 could determine that the DHCP servers 110₁₋₂ are currently unavailable.

Upon detecting that the DHCP servers 110 ₁₋₂ are unavailable, the DHCPserver failover component 130 could be configured to assume the role ofa backup DHCP server for the clients 135 ₁₋₃ on the subnet managed bythe DHCP relay agent 120. As discussed above, the DHCP server failovercomponent 130 could retrieve DHCP server configuration information fromone or both of the DHCP servers 110 ₁₋₂ and could further monitorDHCP-related traffic passing through the DHCP relay agent 120 betweenthe DHCP servers 110 ₁₋₂ and the clients 135 ₁₋₃. The DHCP serverfailover component 130 could then use the DHCP server configurationinformation to determine a range of IP addresses that the DHCP servers110 ₁₋₂ are configured to assign IP addresses within and could furtherdetermine a set of already leased IP addresses based on the monitoredDHCP-related traffic. Based on this, if the client 135 ₁ were to thenrequest an IP address, the DHCP server failover component 130 couldselect an IP address within the determined range of IP addresses thathas not yet been leased to another client and could assign the selectedIP address to the client 135 ₁. Advantageously, doing so allows the DHCPserver failover component 130 to function as a backup DHCP server in theevent that the DHCP servers 110 ₁₋₂ fail or otherwise becomeunavailable.

In one embodiment, the DHCP server failover component 130 may further beconfigured to monitor when one of the DHCP servers 110 ₁₋₂ once againbecomes available. For instance, in the depicted example, once thenetwork disconnect 230 is resolved, the DHCP servers 110 ₁₋₂ may onceagain become available for servicing DHCP requests. In such a scenario,the DHCP server failover component 130 could be configured to transmitupdated lease data to the DHCP servers 110 ₁₋₂, the updated lease dataspecifying IP addresses the DHCP server failover component 130 hasleased out to clients while acting as a backup DHCP server. The DHCPservers 110 ₁₋₂ could then use this updated lease data to update theirown local lease data. The DHCP server failover component 130 could thencease its operations as a backup DHCP server and could resume relayingDHCP-related messages between the clients 135 ₁₋₃ and the DHCP servers110 ₁₋₂. By doing this, the DHCP server failover component 130 ensuresthat the DHCP servers 110 ₁₋₂ are accessing updated lease informationwhen they resume operations

FIG. 3 is a flow diagram illustrating a method for providing a backupDHCP server, according to one embodiment described herein. As shown, themethod 300 begins at step 310, where the DHCP server failover component130 retrieves DHCP server configuration information. Generally, the DHCPserver configuration information specifies the setup of one or more DHCPservers on the network. For instance, the configuration informationcould specify a range of IP addresses that a DHCP server can lease outto DHCP clients. In one embodiment, the configuration informationfurther specifies existing IP address leases by the DHCP server. Suchinformation could include the specific IP addresses that the DHCP serverhas leased and which DHCP clients the IP addresses are leased to. Theconfiguration information may further specify other configurationparameters of the DHCP server, such as a default lease time, a maximumlease time, static IP addresses the DHCP server should assign toparticular devices (e.g., a printer), and so on. Of course, theseexamples are provided without limitation and for illustrative purposes.More generally, the DHCP server configuration information represents anydata related to the setup of a DHCP server.

In retrieving the configuration information, the DHCP server failovercomponent 130 may be configured to transmit a request to one or moreDHCP servers requesting the configuration information. In response tosuch a request, the DHCP servers could be configured to transmit theDHCP server configuration information to the DHCP server failovercomponent 130. In one embodiment, the DHCP server failover component 130is configured to remotely access one or more of the DHCP servers toretrieve the DHCP server configuration information. For instance, theDHCP server failover component 130 could be preconfigured withcredentials information that can be used to remotely access theconfiguration information on the DHCP server. In another embodiment, theDHCP server failover component 130 may be preconfigured (e.g., by anetwork administrator) with the DHCP server configuration information.

The DHCP server failover component 130 then monitors DHCP lease trafficbetween one or more DHCP servers and one or more DHCP clients passingthrough the DHCP server failover component 130 (step 315). The DHCPserver failover component 130 collects lease data based on the monitoredtraffic. For instance, the DHCP server failover component 130 could beconfigured to track which IP addresses each DHCP server has leased outand to which client each IP address was leased. Additionally, the DHCPserver failover component 130 could maintain information such as thetime the DHCP server leased out each IP address.

This monitoring may continue until, at some point, the DHCP serverfailover component 130 determines that the one or more DHCP servers areunavailable (step 320). That is, the DHCP server failover component 130determines a DHCP server is unavailable when the DHCP server failovercomponent 130 is unable to contact the DHCP server. As one of ordinaryskill in the art will appreciate, the DHCP servers could be unavailablefor any number of reasons. As an example, a computer system that a DHCPserver application is running on could experience a hardware failure. Asanother example, the network connection between the DHCP server failovercomponent 130 and the DHCP server could be experiencing problems thatcause the DHCP server failover component 130 to be unable to contact theDHCP server. More generally, however, it is broadly contemplated thatthe DHCP server could be unavailable for any reason preventing the DHCPserver failover component 130 from contacting the DHCP server.

Upon determining the DHCP server is unavailable, the DHCP serverfailover component 130 assumes the role of a backup DHCP server usingthe received configuration information and the lease data collected frommonitoring the DHCP lease traffic (step 325). For instance, the DHCPserver failover component 130 could use the DHCP server configurationinformation to determine a range of IPs that are available for leasingand could use the lease data collected from monitoring the DHCP leasetraffic to determine which IP addresses have already been leased out toDHCP clients. Based on this information, the DHCP server failovercomponent 130 could begin servicing lease requests from DHCP clients,using the IP addresses specified in the DHCP server configurationinformation that have not yet been leased out to a client.

For example, the retrieved DHCP server configuration information couldspecify that the DHCP server is configured to lease IP addresses in therange of 192.168.0.1 through 192.168.0.100. Additionally, by monitoringthe lease traffic flowing past the DHCP server failover component 130,the DHCP server failover component 130 could determine that the DHCPserver has already leased out the IP addresses in the range of192.168.0.1 through 192.168.0.50. Thus, in such an example, uponassuming the role of the backup DHCP server, the DHCP server failovercomponent 130 could service subsequent requests for IP addresses fromDHCP clients using the IP addresses in the range of 192.168.0.51 through192.168.0.100. Advantageously, doing so avoids assigning out anyduplicate IP addresses to two or more of the DHCP clients while stillusing IP addresses in the originally specified range.

The DHCP server failover component 130 may continue servicing requestsfor IP addresses as a backup DHCP server until, at some later point intime, the DHCP server failover component 130 determines that one or moreof the DHCP servers are once again available (step 330). The DHCP serverfailover component 130 then transfers updated lease information to theavailable DHCP server (step 335). Such updated lease information couldinclude, for instance, which IP addresses the DHCP server failovercomponent 130 has leased out to DHCP clients while acting as the backupDHCP server. The lease information could further include which DHCPclients the IP addresses were leased to (e.g., specified using a MACaddress of the client) and the time at which the IP address was leased.Once the updated lease information is transmitted to the DHCP server,the DHCP server failover component 130 ceases acting as a backup DHCPserver and resumes the role of a relay agent between the two subnets(step 340), and the method 300 ends.

FIGS. 4A-B are flow diagrams illustrating methods for monitoring DHCPlease traffic, according to embodiments described herein. As discussedabove, particular embodiments presented herein relate to a networkarchitecture in which DHCP clients are located on a separate subnet fromthe DHCP server and where a DHCP relay agent is configured to transmitmessages between the DHCP clients and DHCP server across the differentsubnets. For purposes of FIGS. 4A-B, assume that the depicted methodsoccur in such an environment. As shown in FIG. 4A, the method 400 beginsat step 410, where a DHCP client transmits a DHCPDISCOVER message. TheDHCP server failover component 130 receives the DHCPDISCOVER messagefrom the client on a first subnet and relays this message to the DHCPserver on a second, different subnet (step 415). Responsive to receivingthe DHCPDISCOVER message, the DHCP server transmits a DHCPOFFER message(step 420). The DHCP server failover component 130 then receives theDHCPOFFER message from the server on the second subnet and relays thismessage to the client on the first subnet (step 425).

Upon receiving the DHCPOFFER message, the DHCP client determines toaccept the offered IP address and transmits a DHCPREQUEST message (step430). Again the DHCP server failover component 130 relays the messagebetween the client on the first subnet and the server on the secondsubnet (step 435). The DHCP server receives the DHCPREQUEST message andtransmits a DHCPACK message in response, confirming the lease of the IPaddress to the DHCP client (step 440). At this point, upon receiving theDHCPACK message, the DHCP server failover component 130 records leaseinformation indicating that the IP address has been assigned to the DHCPclient (step 445). That is, because the lease of the IP address to theclient has been confirmed, the DHCP server failover component 130 isconfigured to record this information for subsequent use should the DHCPserver failover component 130 assume the role of a backup DHCP server.For example, assume the DHCP server offered the IP address of192.168.0.50 to the DHCP client and the client accepted this offer. Insuch an example, the DHCP server failover component 130 could record thelease of the IP address, so that if the DHCP server failover component130 assumes the role of a backup DHCP server, the DHCP server failovercomponent 130 can avoid leasing out the IP address of 192.168.0.50 to adifferent DHCP client and creating a duplicate IP address problem. Uponrecording the lease information, the DHCP server failover component 130relays the DHCPACK message to the DHCP client on the first subnet (step450), and the method 400 ends.

FIG. 4B illustrates a method for monitoring DHCP lease traffic,according to one embodiment presented herein. As shown, the method 460begins at step 470, where a DHCP client on a first subnet transmits aDHCPRELEASE message, indicating that the DHCP client is releasing the IPaddress that it is currently leasing. Upon receiving the DHCPRELEASEmessage, the DHCP server failover component 130 deletes its leaseinformation regarding the released IP address (step 475). That is, sincethe IP address has been released, the DHCP server failover component 130is free to lease this IP address to another DHCP client, should the DHCPserver failover component 130 assume the role of a backup DHCP server.Thus, in the depicted example, the DHCP server failover component 130deletes its locally maintained lease information regarding this IPaddress, indicating that the IP address is once again available forleasing to DHCP clients. The DHCP server failover component 130 thenrelays the DHCPRELEASE message from the DHCP client on the first subnetto the DHCP server on the second, different subnet (step 480. Uponreceiving the DHCPRELEASE message, the DHCP server also deletes itslease information regarding the DHCP client and the released IP address(step 485) and the method 460 ends. The DHCP failover component 130 mayalso monitors for other DHCP messages, such as, DHCPNAK and DHCPDECLINEto keep its lease information in sync with the DHCP servers.Additionally, the DHCP failover component 130 could monitor theexpiration or timeout of a client lease and could delete the leaseinformation for a particular IP address upon detecting an expiration ortimeout of the lease. More generally, the DHCP failover component 130 isconfigured to recognize all current and future DHCP protocol messagesand updates its lease information such that its lease information is insync with the lease information maintained by the DHCP servers.

FIG. 5 is a block diagram illustrating a system configured with a DHCPserver failover component, according to one embodiment described herein.As shown, the system 500 includes a relay agent device 510, a pluralityof and a plurality of DHCP server systems 550, communicatively coupledvia a network 585. In one embodiment, the relay agent device 510represents an existing system, e.g., network devices (i.e., routers,switches, etc.), desktop computers, server computers, laptop computers,and the like. The relay agent device 510 illustrated in FIG. 5, however,is merely an example of a system in which embodiments of the presentinvention may be used. Embodiments of the present invention may beimplemented differently, regardless of whether the computer system is acomplex multi-user computing system, such as a cluster of individualcomputers connected by a high-speed network, single-user workstations,or network appliances lacking non-volatile storage. Moreover, it isexplicitly contemplated that embodiments of the invention may beimplemented using any device or computer system capable of performingthe functions described herein.

As shown, the relay agent device 510 includes, without limitation, aprocessor 515, which obtains instructions and data via a bus 520 from amemory 525. Processor 515 is a programmable logic device that performsinstruction, logic, and mathematical processing, and may berepresentative of one or more CPUs. The relay agent device 510 isoperably connected to the network 545 and the network 585, e.g., vianetwork interfaces.

The memory 525 is any memory sufficiently large to hold the necessaryprograms and data structures. Memory 525 could be one or a combinationof memory devices, including Random Access Memory, nonvolatile or backupmemory (e.g., programmable or Flash memories, read-only memories, etc.).In addition, memory 525 may be considered to include memory physicallylocated elsewhere; for example, on another computer coupled to the relayagent device 510 via bus 520. The memory 525 includes a DHCP serverfailover component 140 and an operating system (“OS”) 535. Operatingsystem 535 is software used for managing the operation of the relayagent device 510. Examples of OS 535 include UNIX, versions of theMicrosoft Windows® operating system and distributions of the Linux®operating system. (Note: Linux is a trademark of Linus Torvalds in theUnited States and other countries.) More generally, any operating system535 capable of performing the functions described herein may be used.

As shown, the relay agent device 510 is communicatively connected to theDHCP client devices 540 via the network 545. The DHCP client devices 540broadly represent any system or device that can be configured with aDHCP client (i.e., software or firmware that is capable of accepting anIP address from a DHCP server). Generally, the relay agent 510 isconfigured to transmit DHCP-related messages from the DHCP clientdevices 540 residing on a first subnet to the DHCP server systems 550residing on a second, different subnet.

Each DHCP server system 550 in the depicted embodiment includes, withoutlimitation, a processor 555, which obtains instructions and data via abus 560 from a memory 570 and storage 565. Processor 555 is aprogrammable logic device that performs instruction, logic, andmathematical processing, and may be representative of one or more CPUs.Storage 565 is representative of hard-disk drives, flash memory devices,optical media and the like. Generally, the storage 565 storesapplication programs and data for use by the DHCP server system 550. TheDHCP server system 550 is operably connected to the network 590, e.g.,via a network interface.

The memory 570 is any memory sufficiently large to hold the necessaryprograms and data structures. Memory 570 could be one or a combinationof memory devices, including Random Access Memory, nonvolatile or backupmemory (e.g., programmable or Flash memories, read-only memories, etc.).In addition, memory 570 and storage 565 may be considered to includememory physically located elsewhere; for example, on another computercoupled to the DHCP server system 550 via bus 560. The memory 570includes a DHCP server application 580 and an OS 575. Operating system575 is software used for managing the operation of the DHCP serversystem 550. Examples of OS 575 include UNIX, versions of the MicrosoftWindows® operating system and distributions of the Linux® operatingsystem. More generally, any operating system 575 capable of performingthe functions described herein may be used.

As discussed above, the DHCP server failover component 130 may monitorDHCP-related traffic flowing through the respective relay agent device510 between the DHCP client devices 540 and the DHCP server systems.Based on this, the DHCP server failover component 130 could determine,for instance, a number of current IP address leases for each of the DHCPservers 580. The DHCP server failover component 130 can also retrieveDHCP server configuration information for the DHCP servers 580,specifying configuration characteristics such as a range of IP addressesa particular DHCP server 580 is configured to lease out, lease duration,maximum lease duration, and so on. The DHCP server failover component130 may then determine that the DHCP servers 580 have become unavailable(e.g., due to a problem in the network 585). In such a situation, theDHCP server failover component 130 could assume the role of a DHCPserver for the DHCP client devices 540, providing leases on IP addressesto the clients 540 using the retrieved DHCP server configurationinformation and based on the monitored DHCP-related traffic.

In the preceding, reference is made to embodiments of the invention.However, the invention is not limited to specific described embodiments.Instead, any combination of the following features and elements, whetherrelated to different embodiments or not, is contemplated to implementand practice the invention. Furthermore, although embodiments of theinvention may achieve advantages over other possible solutions and/orover the prior art, whether or not a particular advantage is achieved bya given embodiment is not limiting of the invention. Thus, the precedingaspects, features, embodiments and advantages are merely illustrativeand are not considered elements or limitations of the appended claimsexcept where explicitly recited in a claim(s). Likewise, reference to“the invention” shall not be construed as a generalization of anyinventive subject matter disclosed herein and shall not be considered tobe an element or limitation of the appended claims except whereexplicitly recited in a claim(s).

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described above with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

Embodiments of the invention may be provided to end users through acloud computing infrastructure. Cloud computing generally refers to theprovision of scalable computing resources as a service over a network.More formally, cloud computing may be defined as a computing capabilitythat provides an abstraction between the computing resource and itsunderlying technical architecture (e.g., servers, storage, networks),enabling convenient, on-demand network access to a shared pool ofconfigurable computing resources that can be rapidly provisioned andreleased with minimal management effort or service provider interaction.Thus, cloud computing allows a user to access virtual computingresources (e.g., storage, data, applications, and even completevirtualized computing systems) in “the cloud,” without regard for theunderlying physical systems (or locations of those systems) used toprovide the computing resources.

Typically, cloud computing resources are provided to a user on apay-per-use basis, where users are charged only for the computingresources actually used (e.g., an amount of storage space consumed by auser or a number of virtualized systems instantiated by the user). Auser can access any of the resources that reside in the cloud at anytime, and from anywhere across the Internet. In context of the presentinvention, the cloud resources could be communicatively coupled acrossmultiple subnets and a DHCP relay agent configured with a DHCP serverfailover component 130 could reside between two of these subnets. Insuch an example, the DHCP server failover component 130 could detectwhen any DHCP server(s) for the subnet for the corresponding subnetbecomes unavailable and could assume the role of a backup DHCP serverservicing DHCP-related requests for the subnet. Doing so helps to ensureproper operation of the cloud resources.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. Each block of the block diagrams and/orflowchart illustrations, and combinations of blocks in the blockdiagrams and/or flowchart illustrations, can be implemented byspecial-purpose hardware-based systems that perform the specifiedfunctions or acts, or combinations of special purpose hardware andcomputer instructions.

While the foregoing is directed to embodiments of the present invention,other and further embodiments of the invention may be devised withoutdeparting from the basic scope thereof, and the scope thereof isdetermined by the claims that follow.

1.-7. (canceled)
 8. A system, comprising: a processor; and a memorycontaining a program that, when executed by the processor, performs anoperation for providing a backup DHCP server, comprising: retrievingDHCP server configuration information specifying a configuration of oneor more DHCP servers; monitoring, at a DHCP relay agent, DHCP leasetraffic between the one or more DHCP servers and one or more DHCPclients passing through the DHCP relay agent; and upon determining thatthe one or more DHCP servers have failed, providing DHCP server servicesat the DHCP relay agent, based on the received DHCP server configurationinformation and the monitored DHCP lease traffic.
 9. The system of claim8, the operation further comprising: upon determining that at least oneof the one or more DHCP servers is operational: transmitting updatedlease information to the at least one operational DHCP servers; andceasing the provided DHCP server services at the DHCP relay agent. 10.The system of claim 8, wherein monitoring DHCP lease traffic furthercomprises: maintaining a list of IP addresses the one or more DHCPservers have leased to the one or more DHCP clients.
 11. The system ofclaim 8, wherein the received DHCP server configuration informationspecifies a range of IP addresses that are available for leasing to DHCPclients.
 12. The system of claim 8, wherein the one or more DHCP serversare located on a first subnet, wherein the one or more DHCP clients arelocated on a second subnet that is different from the first subnet, andwherein the DHCP relay agent is configured to relay traffic between thefirst subnet and the second subnet.
 13. The system of claim 8, whereinretrieving DHCP server configuration information further comprises:transmitting a request for the DHCP server configuration information tothe one or more DHCP servers; and receiving the DHCP serverconfiguration information from the one or more DHCP servers.
 14. Thesystem of claim 8, wherein retrieving DHCP server configurationinformation further comprises: remotely accessing the DHCP serverconfiguration information on the one or more DHCP servers.
 15. Acomputer program product for providing a backup DHCP server, comprising:a computer-readable storage medium having computer readable program codeembodied therewith, the computer readable program code comprising:computer readable program code to retrieve DHCP server configurationinformation specifying a configuration of one or more DHCP servers;computer readable program code to monitor, at a DHCP relay agent, DHCPlease traffic between the one or more DHCP servers and one or more DHCPclients passing through the DHCP relay agent; and computer readableprogram code to, upon determining that the one or more DHCP servers havefailed, provide DHCP server services at the DHCP relay agent, based onthe received DHCP server configuration information and the monitoredDHCP lease traffic.
 16. The computer program product of claim 15, thecomputer readable program code further comprising: computer readableprogram code to, upon determining that at least one of the one or moreDHCP servers is operational: transmit updated lease information to theat least one operational DHCP servers; and cease the provided DHCPserver services at the DHCP relay agent.
 17. The computer programproduct of claim 15, wherein the computer readable program code tomonitor DHCP lease traffic further comprises: computer readable programcode to maintain a list of IP addresses the one or more DHCP servershave leased to the one or more DHCP clients.
 18. The computer programproduct of claim 15, wherein the received DHCP server configurationinformation specifies a range of IP addresses that are available forleasing to DHCP clients.
 19. The computer program product of claim 15,wherein the one or more DHCP servers are located on a first subnet,wherein the one or more DHCP clients are located on a second subnet thatis different from the first subnet, and wherein the DHCP relay agent isconfigured to relay traffic between the first subnet and the secondsubnet.
 20. The computer program product of claim 15, wherein thecomputer readable program code to retrieve DHCP server configurationinformation further comprises: computer readable program code totransmit a request for the DHCP server configuration information to theone or more DHCP servers; and computer readable program code to receivethe DHCP server configuration information from the one or more DHCPservers.
 21. The computer program product of claim 15, wherein thecomputer readable program code to retrieve DHCP server configurationinformation further comprises: computer readable program code toremotely access the DHCP server configuration information on the one ormore DHCP servers.